Summary

Add support for custom TLS certificates when fetching remote Taskfiles over HTTPS. This enables usage in corporate environments with internal CA certificates and mTLS (mutual TLS) authentication.

New CLI flags:

• --cacert - Custom CA certificate for TLS verification
• --cert - Client certificate for mTLS
• --cert-key - Client certificate private key

New config options:

  remote:
    cacert: "/path/to/ca.crt"
    cert: "/path/to/client.crt"
    cert-key: "/path/to/client.key"

Design Decision: Functional Options Pattern

TLS configuration uses functional options (WithCACert(), WithCert(), etc.) rather than direct function parameters. This choice preserves API ergonomics for consumers of the taskfile package:

  // ✅ Current approach - optional, only pass what you need
  node, err := taskfile.NewRootNode(entrypoint, dir, insecure, timeout,
      taskfile.WithCACert("/path/to/ca.crt"),
  )

  // ❌ Alternative rejected - forces all callers to pass empty strings
  node, err := taskfile.NewRootNode(entrypoint, dir, insecure, timeout,
      "", "", "", "",  // caCert, cert, certKey, certKeyPass always required
  )

The TLS options are defined on baseNode (shared by all node types) rather than being HTTP-specific. While only HTTPNode uses these fields today, this design:

1. Keeps the Package API simple and consistent
2. Allows future extension (e.g., Git over HTTPS with custom certs)
3. Avoids breaking API changes if other node types need TLS later

Why no --cert-key-pass?

Encrypted private keys are not supported in this PR. Reasons:

1. Complexity: Go's stdlib only supports legacy PEM encryption (deprecated), and PKCS#8 encrypted keys require external dependencies or custom ASN.1 parsing
2. Niche use case: Most mTLS setups use unencrypted keys (protected by filesystem permissions) or rely on secret managers
3. Easy workaround: Users can decrypt their key beforehand with openssl rsa -in encrypted.key -out decrypted.key

This can be added later if there's demand.